perm filename THESIS.MTG[RDG,DBL] blob sn#606845 filedate 1981-08-18 generic text, type C, neo UTF8
COMMENT ⊗   VALID 00019 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00003 00002	∂19-Jun-81  1827	STT  	AI thesis conspiracy meets Tuesday
C00006 00003	∂20-Jun-81  1419	STT  	mailing list for AI thesis conspiracy  
C00008 00004	∂25-Jun-81  1239	STT  	arrangements for discussion groups
C00012 00005	∂25-Jun-81  1247	STT  	no meeting of "red" group this Friday, unless... 
C00013 00006	∂25-Jun-81  1501	STT  	room change   
C00014 00007	∂28-Jun-81  1804	SJW  	Abstract for Black group meeting next Tuesday    
C00017 00008	∂29-Jun-81  2211	SEK  
C00025 00009	∂06-Jul-81  1109	TGD  	Black meeting (Tues 10 am, MJH 301)    
C00031 00010	∂09-Jul-81  1449	TGD  	RED meeting tomorrow    
C00037 00011	∂13-Jul-81  1726	CPP  	Tuesday's Black Group Meeting
C00042 00012	∂16-Jul-81  2007	STT  	red group meeting tomorrow   
C00045 00013	∂22-Jul-81  1352	STT  	abstract advice    
C00046 00014	∂22-Jul-81  1712	GAC  	Friday meeting
C00052 00015	∂28-Jul-81  1309	TGD  	BLACK thesis group needs speakers 
C00053 00016	∂02-Aug-81  1351	AAM  	Black group   
C00055 00017	∂10-Aug-81  1356	MJM  	Joint group meeting on THURSDAY, Aug.13, MJH 301 
C00058 00018	∂12-Aug-81  0156	BIK   via AMES-TIP  
C00063 00019	∂15-Aug-81  1923	NCR  
C00068 ENDMK
C⊗;
∂19-Jun-81  1827	STT  	AI thesis conspiracy meets Tuesday
To:   "@THESIS.LST[1,STT]" at SU-AI   

Several of us PhD students in AI think it would be useful to get together
in a sort of seminar to discuss our thesis ideas. The main goal is to give
each of us a convenient and more or less friendly audience for our ideas 
and plans.  Secondarily we get to hear what everybody else is doing.
Participants are expected to be at least at the stage of seriously
considering some ideas, and willing to talk about them at one of the
meetings. 
 
The format will be roughly this:  We'll meet for about an hour, once a week.
The person for that week makes some sort of brief presentation to get the
discussion started, and has the primary responsibility to keep it focussed.
Handouts may be useful.  (The best group size is probably four to six, and 
if we get more we might split up. This message is being sent to quite a few
people.)

The first meeting will be held 10:00 am next Tuesday, June 23, on the fourth
floor balcony of MJH.  If you can't make it then but are interested, send
a message to STT@SAIL.  At the first meeting Steve Tappel has volunteered
to talk about his "problem reformulation" ideas.
 
∂TO STT 15:48 21-Jun
See you there.
Yes, I'll come this Tuesday.  Also, I got your message requesting I
postpone posting posters.  What's the reason?
	Russ

∂20-Jun-81  1419	STT  	mailing list for AI thesis conspiracy  
To:   "@THESIS.DIS[1,STT]" at SU-AI   

Rich Pattis suggested people might like to know who was in the distribution
list for the meeting Tuesday. Here's the full list. Have we left anybody out?
The main instigators of the meeting are Tom Dietterich and myself. People
marked with an asterisk participated in a somewhat similar discussion group
last summer and fall.

csd.bennett@score, 	Jim Bennet
csd.berlin@score,	Danny Berlin
klc@sail,		Ken Clarkson	*
csd.pcohen@score,	Paul Cohen
cooper@sumex, 		Greg Cooper	*
jed@sail,		Jim Davidson
csd.dietterich@score,	Tom Dietterich	*
csd.jjf@score,		Jeff Finger
avg@sail,		Anne Gardner
csd.genesereth@score,	Mike Genesereth * (token faculty)
rdg@sail, 		Russ Greiner	*
konolige@sri,		Kurt Konolige
kunz@sumex,		John Kunz
dlo@sail,		Dave Lowe	*
ml@sail,		Mike Lowry
jdm@sail,		Jock Mackinlay
aam@sail,		Allan Miller
rep@sail,		Rich Pattis
csd.cpp@score,		Chuck Paulson	*
ncr@sail,		Neil Rowe
csd.smith@score,	Dave Smith	*
stt@sail, 		Steve Tappel	*
csd.cht@score, 		Chris Tong	*
yue@sail 		Kai-Zhi Yue

∂25-Jun-81  1239	STT  	arrangements for discussion groups
To:   "@THESIS.DIS[1,STT]" at SU-AI   

About thirteen people attended the "thesis conspiracy" meeting this Tuesday.
We have split into two groups, called "red" and "black" after the manner in
which they were chosen. 
All of you who aren't in a group yet are invited to join one, by sending a
message to the relevant coordinator. See below.

Each group will meet once a week. At each meeting one of the members will
introduce some of their thesis ideas (or possibly other research ideas) and
lead a discussion about them. Bull sessions and colloquium-style talks are
both to be avoided. If I may offer some advice, which would have been helpful
for my talk & discussion Tuesday, it is important to:
 (1) Carefully choose a topic which people can reasonably be expected to have
     something to say about,
 (2) Give some concrete examples or whatever to center the discussion around,
     and
 (3) Try to hold people to the topic.

The person who's going to talk and lead the discussion should send around a
short abstract beforehand, to the entire mailing list THESIS.DIS[1,stt] at SAIL.
(This gives members of the group a chance to think about the issues to be
raised and gives members of the other group a chance to attend if they're
specially interested. If you don't have access to the mailing list send your
abstract to one of the coordinators, who will forward it.)

"RED" GROUP
Meeting time & place:	Friday 10:00 am, MJH 252
Coordinator:		Steve Tappel (STT@SAIL)
Members so far:
	Mike Genesereth 
	Russ Greiner
	Beverly Kedzierski
	Scott Kim
	Rich Pattis
	Steve Tappel
	Chris Tong

"BLACK" GROUP
Meeting time & place:	Tuesday 10:00 am, MJH 252
Coordinator:		Tom Dietterich (CSD.DIETTERICH@SCORE)
Members so far:
	Jim Bennet
	Tom Dietterich
	Anne Gardner
	John Kunz
	Mike Lowry
	Marsha Meredith
	Steve Westfold

∂25-Jun-81  1247	STT  	no meeting of "red" group this Friday, unless... 
To:   "@THESIS.DIS[1,STT]" at SU-AI   

Scott Kim says this Friday is out for him. So unless some other red group
member is ready to talk and sends around an abstract TODAY, there will be
no meeting tomorrow. Do we have a volunteer?

Scott is rescheduled for next Friday.

∂25-Jun-81  1501	STT  	room change   
To:   "@THESIS.DIS[1,STT]" at SU-AI   
The powers that be don't want us to use room 252, since it's the nicest room.
Therefore our meetings will be held in room 301 instead, same time, for both
the "red" and "black" groups.

∂28-Jun-81  1804	SJW  	Abstract for Black group meeting next Tuesday    
To:   "@THESIS.DIS[1,STT]" at SU-AI   
			    Beyond Interlisp: 
   Building a Programming Environment Around a Very-High-Level Language

			     Stephen Westfold
			 Tuesday 10:00am, MJH 301

In the CHI project at SCI we are exploring the idea of applying knowledge
based programming techniques to the programming tools themselves in order
to produce more flexible, powerful, better tools.  A major premise of
the work is the desirability of very-high-level languages (these include,
for example, operations on abstract datatypes such as sets and relations).
The problem with such languages is that they are difficult to compile into
efficient code using standard techniques.  The approach we (and others)
take to this problem is one of step-wise refinement whereby high-level
constructs are successively transformed into lower-level constructs using
transformation rules, possibly with some search.

In my thesis work I hope to develop and demonstrate the practicality of
this approach.  One reason for choosing parts of the system itself as
targets is that they are real, practical programs that we are using and
developing, so that any inadequacies in the approach will tend to be obvious.
A more important reason is the feeling that the advantages of very-high-level
language programming will make the tools significantly better as tools.
An example that I have been developing is the specification in rules of
our rule compiler.

∂29-Jun-81  2211	SEK  
To:   "@THESIS.DIS[1,STT]" at SU-AI   
			      Meta-metafont:
  Some radical thoughts on computer graphics and programming languages.

				Scott Kim
			 Friday 10:00am, MJH 301

My thesis project will be to build a successor to Metafont. Metafont is a
programming language built by Knuth for designing typefaces--the output of
a Metafont program is a set of character images represented as bit
matrices. My system will also be used for designing typefaces, but the
style of interaction will be very different. Metafont is a batch-oriented
language, whereas my system will be intrinsically interactive.

The project has two primary goals:

(1) The first goal is practical:  The system should be useful to actual
typeface designers. This means a great deal of attention to the user
interface, involving careful study of how designers actually work as well
as good criticism.

(2) The second goal is more theoretical and far less understood.  Every
computer graphics language that I know of is in fact textual:  the output
is pictures, but the language that represents the output is made of typed
characters. Since program and data are in different forms, the language
cannot have the power model itself. In Lisp, program and data are both
represented as lists, and this uniformity leads to a richness that is not
found in weaker computer languages. What I want to explore further is the
possibility of a language in which program and data are both graphical.
I don't know what the implications of such a paradigm shift will be, but
I have the strong feeling that it is both possible and valuable.

Friday I want to discuss some of the issues which have come up in the
course of pondering the question "What is a programming language?"  I will
present a number of systems which are almost but not quite programming
languages and ask how the differences can be classified. The discussion will
venture far beyond the usual taxonomy of finite-state automata and Turing
machines, into areas which I find exciting but disorienting.

∂From SEK 12:56PM 3-Jul
Here are some scattered memories from Friday July 3's thesis consipiracy.
Please feel free to add observations and questions which were of particular
interest to you.

David: 

Beverly: referring to negative space. Isn't this related to work in
animation: key frame interpolation? This is a bit far-fetched, but what
about the SF image of a dusty alien library full of books that contain
pictures and sounds, but no words? Image of a moldable clay terminal.

Dan: (imagining an actual terminal interaction) there would be a period of
time in which you agree on what refers to what, e.g. what you mean when
you refer to the left bar of an A. You draw the picture, then attach
names.

Russ: Fortran feels closed--there are things which you really can't say in
the language. For instance you can't talk about numbers in TEX. Lisp, in
contrast, feels more open. I understand why you might want graphical
arguments, but why graphically represented function names?

Steve: We already have a graphic expressive language: gestures.

Marsha: That's funny; instead of shaving off the bottom of the stroke of
the A, I thought of pushing something in.

Scott: My language should have multiple representations of what a
character is (pixel, outline, stroke, area).  A complete graphics language
should include a vision system, so that the language is able to refer to
what the user can see. What should I call my language, a graphical
graphics language? Image: Fortran do loop represented more and more
graphically (substitute diagrams and symbols for numbers and letters),
contrasted with letter A represented more and more textually (add
annotations to clarify the meaning of a drawing).  The first image gives
you the misleading impression that a graphical language is nothing but a
picture-coated respresentation of what is actually a textual language. In
fact, some things are more appropriately represented as pictures, and it
is precisely those things which I expect would benefit from a graphically
based language. I want to do for graphics what Lisp does for symbol
manipulation.

Image I didn't give in the lecture: graphics languages are virtually
always based on textual languages. Example: letter shapes coded in
Metafont.  Actually there are lower levels (assembly language,
physics...), but we can seal them off, ignore them, and still get what
feels like a complete understanding of what's going on. I want to reverse
the emphasis: a language which bottoms out on graphics.

∂06-Jul-81  1109	TGD  	Black meeting (Tues 10 am, MJH 301)    
To:   "@THESIS.DIS[1,STT]" at SU-AI   
Black group meeting, Tuesday Jul 7, 10 am in MJH 301.
Discussion person: Tom Dietterich

I am currently trying to formulate a thesis proposal on learning.
Most current learning programs start with an expert-supplied
set of terms (features, predicates, etc.) and connectives (AND, OR, NOT)
and search the space of possible sentences written using the terms and connectives
for a sentence (concept, rule, etc.) that is consistent with the training instances
and that satisfies some other constraints (simplicity, plausibility, etc.).

I am interested in attempting to have a program rationally select the terms
and connectives (i.e., the description language) to search.  I would
like to have a system come up with reasons for (and against) including each
possible term.  The system could alternate between a "select terms" step
and a "learning" step.  Once it selected some terms, it could conduct
the "learning search", and depending upon the outcome of that search, it could
modify its choice of terms and repeat the process.  The thesis thus aims
at making explicit a body of knowledge about how to determine how some
terms are relevant to some partially understood phenomenon.
Of course, in the long run it would be desireable to have a system learn
precisely this knowledge so that it could improve its learning ability.

There are many directions the research could take, and I'd like the group
to give me advice on what domain might be suitable and on which of these
directions I should pursue:

1. The iterative approach to selecting and then learning could evolve into
a sort of combined system in which the program started with a very trivial
language and gradually expanded and modified it.

2.  I could concentrate on new term invention.  Could the system start with a
"vague" model of the phenomenon and by common sense reasoning and analogy
develop the relevant terms (and ways of measuring them).

3. Another approach to term invention that has received some (reletively little)
attention is the process of inventing new terms by combining old terms.
I could work on this problem. (easier than 2.)

4. Another problem in learning is learning with disjunctions.  When a disjunctive
connective is added into the description language, least-committment generalization
searches such as Mitchell's candidate elimination algorithm or any of the 
breadth-first algorithms explode.  The solution seems to be some kind of
heuristic search and some approach to understanding exactly what
kinds of disjunction are useful/desirable.

5.  Yet another set of problems are raised in situations that are noisy.
If the training instances are noisy, other knowledge must be brought to bear
to guide the search of description space.  

6. The biggest area of research is probably in the strategies for suggesting
and justifying the incorporation of certain terms in the representation language.
What kinds of strategies can be used?  One approach might be to make up a
"story" about how the unknown phenomenon works and then incorporate those
variables that participate in the "story".  In chess endgames, for example,
a program might reason that pinning a piece against the edge of the board is
a good strategy and thus develop a set of features that measure "opportunity
to pin", etc.  These features could then be used to learn from examples of
chess endgames.


∂09-Jul-81  1449	TGD  	RED meeting tomorrow    
To:   "@THESIS.DIS[1,STT]" at SU-AI
CC:   darden at SUMEX-AIM 
RED group meeting, Friday Jul 9, 10 am in MJH 301.
Discussion person: Tom Dietterich  (YES, I'm talking to the
RED group too!)

I am currently trying to formulate a thesis proposal on learning.
Most current learning programs start with an expert-supplied set of
terms (features, predicates, etc.) and connectives (AND, OR, NOT) and
search the space of possible sentences written using the terms and
connectives for a sentence (concept, rule, etc.) that is consistent
with the training instances and that satisfies some other constraints
(simplicity, plausibility, etc.).

I am interested in attempting to have a program rationally select the
terms and connectives (i.e., the description language) to search.  I
would like to have a system come up with reasons for (and against)
including each possible term.  The system could alternate between a
"select terms" step and a "learning" step.  Once it selected some
terms, it could conduct the "learning search", and depending upon the
outcome of that search, it could modify its choice of terms and repeat
the process.  The thesis thus aims at making explicit a body of
knowledge about how to determine how some terms are relevant to some
partially understood phenomenon.  This is a version of the
circumscription problem: how can the learning program circumscribe the
problem so that it can generate plausible hypotheses?

There are many directions the research could take, and I'd like the
group to give me advice on what domain might be suitable and on which
of these directions I should pursue:

1.  The biggest area of research is the elucidation of strategies for
selecting relevant terms.  Most previous work in this area has used
simple spreading activation in a network to select relevant terms.  I
suspect that the next level of sophistication involves developing, for
each term or group of terms, a "half-baked" hypothesis about how those
terms affect the phenomenon of interest.  For example, if the system
is attempting to discover what causes lung cancer, it might suspect
that airborne particles are important because the air comes into
contact with the lungs.  This could lead the system to look at terms
describing properties of the air breathed by patients.

By introducing these "term relevance hypotheses", I am introducing a
second level of hypothesis formation into the learning system.  These
hypotheses are different from hypotheses about what combination of
terms provides a necessary and sufficient condition for some
phenomenon to occur.  

2. A second direction for research could be the development of new
terms.  Existing work on new terms creates new terms by combining
previous terms using connectives such as AND, OR, FUNCTION
COMPOSITION,  PROJECTION, etc.  I suspect that the development of new
terms will require a deeper representation of the semantics of terms--
particularly partial definitions of terms using necessary conditions,
sufficient conditions, effects, causes, exemplars and nonexemplars,
etc.

3.  A third direction for research would be learning from disjunction.
When a disjunctive connective is added to the description language,
least-committment generalization searches such as Mitchell's candidate
elimination algorithm explode.  The solution seems to be some kind of
heuristic search and some approach to understanding exactly what kinds
of disjunction are useful.

4.  Finally, I could focus on problems of learning in the presence of
noise and uncertain observations.  Very little work has been done on
this problem.

∂13-Jul-81  1726	CPP  	Tuesday's Black Group Meeting
To:   "@THESIS.DIS[1,STT]" at SU-AI   
							Chuck Paulson
							July 13, 1981

		Representation of Control

	Programs can be thought of as consisting of three parts.  They are
the data structures, the atomic operations on those data stuctures, and the
control or ordering of those operations in the program.  This talk will be
concerned with the representation of the latter component.
	Control has been rather opaque in traditional languages, ie. it is not
clear why a certain control structure is used and it is certainly the case that
the program itself doesn't know about its control structure, or how to change
it.  Control is usually hard to modify in a given program and it is also not at
all clear how to deal with parallel operations.  Lately several attempts have
been made to understand and represent control structure in order to analyze
control and give the program knowledge of its own control.

	Some methods have been:

1) Traditional Programming Languages (compilers look at control flow a little)
2) Petri Net Models
3) Finite State Machine Models
4) Production Rules
5) AMORD System (MIT, by deKleer, Doyle, Rich, Steele, and Sussman)
	Rule based system with TMS, pattern-directed invocation, explicit
	representation of control.
6) Chuck Reiger's CSA representation.  Uses a large causal network with many
	different flavors of causality.
7) BDL, the DART system representation.  A combination of petri nets,
	procedural nets, and Reiger's rep.
8) Programmer's Apprentice Plans.  Has explicit control links within a plan.
	They look like railroad tracks.  Plans include data links, control
	links, and other plans in hierarchical fashion.
9) Sacerdoti's procedual nets.  Are hierarchical, explicitly include partial
	ordering of actions.

	There are undoubtedly more representations which I have neglected to
include.  These give a starting base from which to work outward.  Some problems
in representation of control and examples of them follow:

1) Duration of operations (race conditions)
2) How ordering of operations affects resources (deadlocks)
3) Figuring out and representing constraints on partially parallel actions
	(trying to optimize a pipeline or an IBM 360/91 floating point unit)
4) Transforming conceptually parallel operations into serial ones so that a
	single resource can handle them.
	(multi-port memory, timesharing on a computer,
	this is the concept of a serial resource controller)
5) Making control easy to understand and transparent to the user
	(occurs to everyone trying to understand other people's code,
	PA is working on this problem)

∂16-Jul-81  2007	STT  	red group meeting tomorrow   
To:   "@THESIS.DIS[1,STT]" at SU-AI   
Rich Pattis will discuss his ideas on debugger design this Friday,
at our usual meeting time and place (10:00 am, MJH 301.)
Below is a message from Rich; please note that his second abstract 
is the main one for tomorrow.

-----
 
 ∂16-Jul-81  1502	KLC  
Steve, here is a combination of the abstracts of the two talks I gave to
the debugging seminar.  They indicate what I'll focus on during my talk
tomorrow....Rich


  I plan to survey the debuggers mentioned in the reference list below.  I'll
start by describing some of the features of the LISP-Machine/INTERLISP & MESA
debuggers and their interpreted/compiled environment.  Then I'll review the
outstanding features of the research debuggers mentioned below, most of which
never made it into everyday use.  The review will be carried out in depth,
some to the level of implementation details, as the time/information tradeoffs
made in these systems are interesting.  I'd like to conduct this seminar meeting
as more of an open discussion, as opposed to a straight lecture.

  I plan to present a proposal for a high level debugger, mostly concentrating
on its post-mortem aspects.  I am assumming that the host machine is a large,
personal computer (ala SPICE).  I will discuss issues concerning how to organize
and store the execution history of a program, and how to effectively access (with
a debugging languge) this information.  I will try to convince everyone that not
a too great price (in time) must be paid for this type of debugger, and that
a large increase in debugging productivity can result.

∂22-Jul-81  1352	STT  	abstract advice    
To:   "@THESIS.DIS[1,STT]" at SU-AI   
Don't take this too seriously, folks, but here is a suggested outline for
abstracts and discussions. I hope it is of some use.
 
your research topic
	be as specific as you can
	supply background if required

intended contribution to AI

current status

question to be discussed
	important to your research
	a question that people can realistically be expected to have ideas about
	recommend that you have examples ready to focus discussion

∂22-Jul-81  1712	GAC  	Friday meeting
To:   "@THESIS.DIS[1,STT]" at SU-AI   
RED (and BLACK?) group meeting 10:00 a.m. Friday 24 July, MJH 301.

Speaker: Gray Clossman


		Self-Monitoring in an AI program

	I want to present a control structure that may allow a program to
monitor itself and detect loops in its behavior.  This ability is necessary
for an AI program that operates in a description-rich domain by means of
redundant and potentially circular transformations on descriptions.  The
Seek-Whence (SW) program, currently being implemented by MJM, DRH, and GAC,
is such a program.  SW discovers and manipulates descriptions of patterns in
the toy world of integer sequences.  I would like for SW to monitor itself
to the extent that it would detect loops in its behavior, and represent and
reason with that information.  A loop in the behavior of SW is a recurrence
of a description that has earlier been generated by the program.  Different
types of recurrences can serve as indications that the program is in a rut
(a bad loop), or that the description that has been regenerated has recurred
as a good idea that deserves more attention.

	SW maintains several competing descriptions (of a sequence) and
theories (predictive rules for the sequence) as it tries to arrive at `good'
theories for the sequence.  A good theory is one that many people would give
as the rule that generates the sequence.  SW uses a HEARSAY-II-like Blackboard
and parallel control structure.  Among the ways in which it differs from HSII
are two points of interest here:

1)	The production rules for transforming information into different forms
and moving it up and down (among levels of description) on the Blackboard will
be richly redundant.  Every production, P, will result in a change to the data
structures on the Blackboard.  "P(a) -> b" means that if predicate <P> detects
pattern <a> on the Blackboard, then structure <b> (which is usually built from
<a>) may be asserted (i.e., linked into the Blackboard).  In SW's redundant
productions, many productions will have inverses: "P(a) -> b" and "P(b) -> a".
Such productions allow -- even encourage -- loops in SW's behavior.

2)	SW will not use an overseer-scheduler to notice loops and be arbitrer.
There will be no global "goal-directed scheduling function" as in HSII; no
global, wise conflict-resolver.  Control will be largely in the hands of demons
(productions).

	Obviously, SW must monitor its progress and avoid looping endlessly
through circular reformulations of sequence descriptions.  I propose that
when a description on the Blackboard is changed (summarized, restructured, or
deleted) by a production, a new production be generated that will "recognize"
that description if it later recurs.  The new production should also record
the action taken when the description was last encountered.  When that
description is re-encountered, a different action may be taken.

I would like to explore the questions:

	What does "to monitor self" really mean?

	How does "self monitor" differ from "self model"?

	I am pushing control information into representation-language
data-structures on the Blackboard so that the (concurrently-executing
sameness-detecting demons of the) program can detect patterns of behavior.
What are the implications of annotating control in the representation language?

∂28-Jul-81  1309	TGD  	BLACK thesis group needs speakers 
To:   "@THESIS.DIS[1,STT]" at SU-AI   
The BLACK group needs people to volunteer to speak.  So far, only
Tappel, Westfold, Dietterich, and Paulson have given talks.  We'd
like to hear from the rest of you (or from anyone who wants to talk
a second time).  As you are no doubt aware, the BLACK group has
not met for the past two weeks.  I've been too busy to line up a
speaker for each week.

--Tom

∂02-Aug-81  1351	AAM  	Black group   
To:   "@THESIS.DIS[1,STT]" at SU-AI   
I will be speaking on Tuesday, August 11 (a week from next Tues.) at 10 AM
in MJH 301.  I'll talk about

 . What kind of problems are being solved in computer vision research
 . Why these problems need more compute power
 . Ways to provide the compute power needed
 . Problems associated with VLSI implementations of array processors

I have a few slides I prepared for a previous presentation.  If you would like
to read something before the meeting, I wrote a short (two-page) paper which
appeared in the latest proceedings of the Image Understanding workshop.  I
have reprints of this paper; see either me in room 030A or Marianne Siroker
in room 030.
					Allan

∂10-Aug-81  1356	MJM  	Joint group meeting on THURSDAY, Aug.13, MJH 301 
To:   "@THESIS.DIS[1,STT]" at SU-AI   
		BUILDING A BASIS FOR ACTIVE CONCEPTS


	The ability to classify, to make common abstractions, to reason by
analogy, to detect patterns is fundamental to human intelligence.  People do this
continually, with or without conscious volition.  A purse can remind us of a
pocket, a weapon, a particular person, or any number of other things.  One story
reminds us of another.  Such phenomena seem to point toward the existence of
"active concepts", concepts which 
	(1) are malleable, stretchable;
	(2) can insinuate themselves into an ongoing thought process;
	(3) are manipulated and operate at pre-verbal, "thought-collecting" levels.

	My proposal is that an attempt can be made to construct such active
concepts in a world more amenable to analysis than natural language.  The 
chosen vehicle is representation of patterns expressed as integer sequences.
The SEEK-WHENCE project involves characterizing sequence patterns in terms of 
S-W "diagrams", objects with both structural and procedural aspects, based on
a small group of redundant "primitive" structuring notions.  The "theory" (final
predictive diagram) for a pattern is derived from the sequence of input terms
by a "Schoolhouse" system reminiscent of the HEARSAY-II architecture, but with
a few new twists.  It is hoped that the process of diagram creation can be
made to leave behind a trail of active agents which, along with the final diagram,
could become the main portion of a "Concept" for that sequence.  If this can
be done successfully, such notions as common abstraction, conceptual closeness,
and reminding could be studied.  Certainly, a study of analogy would be
possible.


	My talk will be on THURSDAY, August 13th in MJH 301.  I welcome
questions, suggestions, and references.

∂12-Aug-81  0156	BIK   via AMES-TIP  
To:   "@THESIS.DIS[1,STT]" at SU-AI   
This Friday, August 14th at 10:30am in MJH 301, I will give a talk to  the
Red Group (and whoever else shows up) on my Ph.D. thesis work.

The research  involves  the  creation  of  a  System  Development  Support
Environment to assist  in communication and  management tasks of  software
project members, thus  aiding in  the development  of large,  evolutionary
systems.  I am  using a knowledge-based  synthesis approach while  dealing
with a Human Factors issue.

The  environemnt  should  include  INTEGRATED  capabilities  for   project
management,  system   evaluation,   documentation/help   and   intelligent
communication between designer/users  and the system  or other  designers.
Collecting, organizing  and  dissemination information  about  a  project,
using  a  model  of  the  underlying  system,  raise  database,  knowledge
representation and  interface  issues,  including the  use  of  formal  vs
natural languages.

The work is  centered on  an idea I  have developed,  that people  perform
"Comunication Acts", such as:  questioning, griping, planning,  requesting
or informing,  while interacting  with  a system.   These are  similar  to
Speech Acts of Linguistics, and are often dealt with in Office  Automation
work.  A Taxonomy of these "Acts" has been created from initial,  informal
experiments.  They will  be presented, along  with the environmemt  design
and framework, a scenario, workplan and progress report.

I will have slides prepared, since I have to give a presentation Monday at
Systems Control,  Inc.  and  could  use part  of  this talk  as  practice.
Actually, our group  (Cordell Green, my  advisor, et al)  is now  formally
Kestrel Institute.

My thesis  topic was  approved a  year ago  April. Since  the work  is  so
interdisciplinary, I  have  approached  it from  many  angles.   There  is
currently an  initial  implementation  of  some  of  the  ideas.   I  have
incorporated all my written material into a report that has been submitted
for separate government funding. I may pass out the table of contents from
that report to initiate discussion.

After the initial presentation, I  would appreciate feedback on  questions
such as: (1) What do you, as  system users and builders, imagine to be  in
an ideal  support environment?   [For now,  I am  not emphasizing  program
maintenace issues] and (2) Which areas of this work should be stressed and
which should be avoided?  If there is time, I may pose some problems, from
data I have collected, to see how many tasks you could imagine  fulfilling
as an ideal, intelligent  system support environment,  and in what  manner
you believe the processing should take place.

∂15-Aug-81  1923	NCR  
To:   "@THESIS.DIS[1,STT]" at SU-AI   
I will give a talk on Tuesday, August 18 at 10 A.M. in Jacks 301
to the Black group and anyone interested from the Red group.  Topic: a
rule-based system to calculate descriptive statistics on a database. 

The setting is an extremely large database such as a governmental
organization or large company might have.  For such databases,
statistical analyses are a primary usage.  But most interesting
statistical calculations require essentially random access to many
records on secondary storage, running up enormous amounts of time.  A
possible solution is to precompute some descriptive statistics for
commonly asked-about sets.  The problem with this is that there are just
too many such sets.  An arbitrary number of sets can be combined by
intersections, unions, and complements to make new sets, and an
unlimited number of sets can be defined on a continuous-valued
attribute.

Our approach is to precompute some statistical information for simple
sets that a user might query, and try to derive statistics for other
sets from these.  For instance, the statistics for American tankers are
probably something like the statistics for American ships and for
tankers.  At least the largest American tanker cannot be larger than
either the largest American ship or largest tanker; and so on.

We can write a number of such rules to get statistics of complicated
sets in terms of algebraic combinations of statistics on simpler sets.
This represents a modification of the concept of "inheritance" as it is
known in AI.  Modifications are necessary because statistical properties
of a sibling node rarely inherit directly from the parent; the average
American tanker length is unlikely to be the average American ship
length.  Similarly, the most common cargo on an American tanker is
unlikely to be the most common cargo on an American ship.

Integrating several hundred statistical derivation rules into a
production system raises interesting questions of control architecture
which we are just starting to address.  Note this production system will
be unusual in that the best of possible rules should not be "selected"
-- all possible rules should be fired in parallel, to give the tightest
possible constraints on an uncertain answer.

There are also interesting problems about queries about prototypes and
analogies.  For instance, does the prototypical American tanker have the
mean size of members of its set?  Or maybe the mode size?  And AI does
not seem to have a notion of dispersion in the range of property values
a prototype can have, a notion which our work suggests is critical.